
WARN ING : This column con tains in flammatory mater¬ 
ial. It is likely to raise the blood pressure of Smalltalk 
vendors If you are an easily inflamed person, and you 
don't care much about what your customers want or 
need, press"n"now (and start reading Chapter 11!) 






s Smalltalk finds wider use and new vendors ap¬ 
pear, the trend is clear: Smalltalk developers need to 
be protected from themselves. Those pesky devel¬ 
opers are so demanding—they want to change every¬ 
thing, and then have their changes supported, too! (Exit 
cynic mode—we realizeopen environmenttechnical sup¬ 
port is no easy task.) 

Oneway out of this mess is well-specified interfaces. If 
Smalltalk vendors had the technical facilities to draw a 
ine in the sand and say “pass this, and you're on your 
own," users and vendors could work together to deter¬ 
mine the appropriate cost for different levels of support. 
But the easy way out is to simply remove access to the 
source code, without even specifying a system program¬ 
ming interface (SPI). 

Everybody is talking about “application programmer 
interfaces" (APIs) these days, but they are forgetting that 
not everybody is an “application programmer." The 
beauty of Smalltalk is that it works both as a systems 
anguage and an applications language. With persistent 
rumors that the new regime at ParcPIace-Digitalk is 
considering “protecting developers from themselves," 
we've decided to publish some of our favorite Smalltalk 
system programming examples. Most of these examples 
will only work with VisualWorks today. Tomorrow, they 
may not work with VisualWorks either. 


COMPILER MACROS 

New users of Smal Ital k often react with a sense of wonder 
when they discover that all control constructs are actual¬ 
ly implemented in the language. One of those new users 
was a project leader at one of our clients. 


“You know what I really miss about C," he said, “is the 
'question-colon' operator." Upon closer questioning, we 
discovered that what he really wanted was a quick and 
simple way of dealing with uninitialized variables. 

“Okay, let's implement it!" we replied. “Hmmm...it 
needs to be simple...don't want a bunch of parentheses 
everywhere.. .sounds like a binary message to me." 

Object 
? block 

"If I am not nil, answer myself, otherwise answer 
the value of <block>. 

UndefinedObject 
? block 

"If I am not nil, answer myself, otherwise answer 
the value of <block>. 

''block value 

This allows you to easily protect against unwanted nils, 
therefore making your system more robust. For example, 
you might have a method that prompts the user for a String, 
but you want a reasonable default: 

Dialog request: message ? [Type something, will ya? 

We're paying for this stuff!'] 

This avoids having to use a conditional assignment to a 
temporary variable, and is also quite easy to read. Also, it 
doesn't involve any “systems" programming, yet. On the 
other hand, a message send is involved, which costs a bit 
more time than ifTrue:ifFalse: does. 

“But why should it cost more?" our client asked. It did¬ 
n't take more than a few minutes of rummaging around 
the compiler to come up with the answer: it needn't 
cost more. Add the method in Listing 1 to MessageNode, 
keeping in mind the warnings we gave about base modi¬ 
fications in the July issue 1 (We put this and similar ex¬ 
tensions in a separate ENVY application called 
CompilationBytesmiths). Evaluate 
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(MessageNode classPool at: #MacroSelectors) 
at: #? put: #transformlfNil 

(Using ENVY, we put this expression, and other simi¬ 
lar ones below, in CompilationBytesmiths class»loaded, 
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Listing 1. 


Message Node 

transformlfNil 

"If the receiver is nil, evaluate the argument. MacroSelectors associate this action with the selector #?." 

''((arguments first isBIockWithNumArgs: 0) and: [receiver hasEffect not]) ifTrue: 

[receiver : = self class new 
receiver: receiver 
selector: #== 

arguments: (Array with: (LiteralNode new value: nil)), 
self makelfTrue: arguments first ifFalse: (BlockNode new body: receiver receiver)] 

Listing 2. 

MessageNode 

transformlflnDevelopment 

"If the system is not in development, remove this message. If the system is in development, insert the argument 
block's statements. MacroSelectors associate this action with the selector #ifl nDevelopment:." 

"self halt, self iflnDevelopment: [Transcript cr; show: Tup, I'm in development.']. 27 = 21" 

''((self respondsTo: #islnDevelopment) and: [self islnDevelopment]) 
ifTrue: [receiver := arguments first body] 
ifFalse: [receiver : = SequenceNode new statements: #()] 


Listing 3. 

MessageNode 

tran sf orm Ru nti meNoOp 

"If the system is not in development remove this message. If the system is in development, generate the message. 
MacroSelectors associate this action with the selectors #debug, #debug:, and #halt." 

''((self respondsTo: #isi nDevelopment) and: [self isl nDevelopment]) 
ifFalse: [receiver : = SequenceNode new statements: #()] 


and also added a removing method to get rid of these 
new "macro selectors" when CompilationBytesmiths is 
removed). 

Now when ? appears in your code with a simple receiv¬ 
er, the compiler “in-linesf it into a test for nil and acondi- 
tional branch, thesamewayit deals with ifTrue: and other 
"fake" messages—no message sends involved. Some sim¬ 
ple timings show it to be about 30% faster without the 
message sends. 

This is kind of cute, but the few microseconds it saves 
is hardly going to make or break a project. However, this 
basic mechanism can be exploited to strip your code of 
debug statements and assertions 

Assertions are like bran cereal—everybody agrees its 
good for you, but nobody really likes the taste. Smalltalk 
assertions typically steal cycles from you even beyond the 
development phase where they’re needed. What assertion 
writersrea//ywant istheC preprocessor, so that when you 
hit "#ifdef DEBUG" on your final compile, the assertion 
code simply goes away. Well, we’ve got access to the Visu¬ 
al Works compiler, so let’s do it! 

First, establish a predicate for all manner of develop¬ 
ment-only code. We define an ENVY application called 
TestingBytesmiths that olds our test management frame¬ 
work; its presence is an ideal development predicate: 


Object 

isl nDevelopment 

"Is this a development image? Since this consumes 
runtime, avoid using this in performance critical 
code." 

''Smalltalk includesKey: #TestingBytesmiths 

As the comment indicates, a dictionary look-up isa rather 
heavy price to pay to find out you don’t want to print a 
Transcript message in a production environment!To fur¬ 
ther encapsulate this, wealso have a conditional action: 

Object 

iflnDevelopment: block 

"If this image is in a ‘development’ state (whatever 
that means), do <block>, otherwise do nothing. In 
either case, answer self. Since this consumes 
runtime in either case, avoid using this in 
performance 
critical code.” 

self isl nDevelopment ifTrue: [block value] 

In fact, the greater encapsulation of the conditional action 
is much preferred, as you’ll see shortly—the predicate 
method isl nDevelopment should be considered private. 
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Listing 4. 

ifFalse: "No temp declarations yet; have to insert whole line" 

["Added/ modified by Bytesmiths, on 7 October 1995: figure out how many tabs to insert." 
tabs := 1. 

[(editor text at: endTemps - tabs) == Character tab] whileTrue: [tabs: = tabs +1], 
replacement : = '| name,' | 

(tabs = 1 
ifTrue: ["] 

ifFalse: [(String new: tabs withAII: Character tab) at: 1 put: Character cr; yourself]) 
"***** enc l addition/ modification*****"], 
editor selectAt: endTemps. 


Listing 5. 


CompiledMethod 

setSpecif ication From Sou rce: source 

"Set my comment user field to the comment contained in <source>, my 
source code." 

comments comment args charSet | 
comments : = Compiler preferredParserClass new 
parseMethodComment: source setPattern: [:x | ]. 
comments size >0 ifFalse: ["'self]. 

comment : = TextStream on: (String new: 100). 
args := (Compiler preferredParserClass new 
parseArgsAndTemps: source 
notifying: nil) readStream. 
self selector numArgs = 0 

ifTrue: [comment emphasis: #bold; nextPutAII: selector] 
ifFalse: 

[self selector keywords do: [:kw | 
comment 

emphasis: #bold; nextPutAII: kw; space; 
emphasis: #italic; nextPutAII: args next; space]], 
comment emphasis: nil. 

args := args contents copyFrom: 1 to: self selector numArgs. 
charSet : = 

'abedefghijkImnopqrstuvwxyzABCDEFGHIJ KLMNOPQRSTUVWXYZ' asSet. 
comments do: [:cmt | | cmtStream | 
cmtStream : = cmt readStream. 
comment cr; tab. 

[cmtStream atEnd] whileFalse: [ | pair | 

pair : = cmtStream nextWordAndNonWordDefinedBy: charSet. 
(args includes: pair first) 


Remember the? example?lt pays back the effort it took 
to understand it when used as a pattern for stripping out 
development-specific code (see Listi ng 2). 

Let the compiler know you’ve defined a new macro. 
If you’re using ENVY, remember to put this in your loaded 
method, and to remove your macro selector in your 
removing method. 

(MessageNode classPool at: #MacroSelectors) 
at: #ifl nDevelopment put: 

#transforml fl n Development 

Now if you do the comment expression i n the above meth¬ 


od, and step through therta/t, you will see 
the following decompiled code in a 
"development" image: 

self halt. 

Transcript cr; show: 'Yup, I'm in 

development.'. 

27 = 27 

and if you temporarily redefine 
Object»i si nDevelopment to answer false, 
the decompiled code will look like 

self halt. 

27 = 27 

all without a single "#ifdef"! We also in¬ 
line other conditional development-time 
messages usi ng the code in Listing 3.This 
works because there is no "ifTrue:" part, 
so it returns nil when not in develop¬ 
ment, which tells the sender to generate 
the original message send, instead of 
generating an in-line bytecode sequence. 
We can hear some of the Smalltalk ven¬ 
dors who hide their compiler mumbling 
something in the background like "we 
can provide 'hooks' to do things like 
that." Great—we’re happy they can per¬ 
fectly anticipate all the potential uses one 
might make of the compiler! But what 
about their compiler bugs? (No, they 
don't have compiler bugs!) 

COMPILER BUG FIXES 

Some of these are controversial, and some may well be a 
minority opinion, but our point is that without compiler 
source code, we would not even have a choice about deal¬ 
ing with, shall we say, "undesired compiler behavior." 

Most Smalltalk dialects have block temporary vari¬ 
ables, and using block temporary variables whenever 
possiblecan have an important performance benefit. For 
simple cases, we’ve measured a 100% speed penalty when 
using method temporaries instead of block temporaries. 

Yet the "helpful" Visual Works compiler always places 
undeclared temporaries in the method context.This often 
causes what could be a "clean" block to be a "copying" 
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MANAGING OBJECTS continued from page20 

we hosted, John Brant presented a code quality tool he is 
working on at University of Illinois, Urbana-Champaign 
that goes far beyond what we have done. He expects to 
make it widely available when completed, but if the sys¬ 
tem-level classes he exploits become "protected," such a 
thing might not be possible. Emerging coverage tools that 
do bytecode manipulation might also be threatened. 

CONCLUSION 

As Smalltalk enters mainstream management information 
system shops, Smalltalk vendors claim there is a need to 
"protect developers from themselves." They propose to do 
this by removing source code and by supplying "hooks" to 
anticipated "APIs." This flies in the face of conventional 
wisdom about reuse. Reuse often involves modifications 
and extensions; it usually is discovered, harvested, reengi¬ 
neered, and sought out, but it is rarely anticipated. 

We feel this argument is a thinly disguised way of re¬ 
ducing support costs, which is better addressed by clearly 


defining SPIs in such a way that both system and applica¬ 
tion programmers know when they've overstepped their 
limits (and their support contracts!) 

The power of Smalltalk comes from many different 
aspects and trying to be more like Visual Basic, Pow¬ 
erBuilder, or Hot Java by reducing access to "dangerous" 
(i.e., "hard to support") system features in the name of 
making things "safe" for application programmers is like¬ 
ly to have a detrimental effect. 

If you wanttodo some of the things in thiscolumn, but 
your Smalltalk dialect doesn't have the proper hooks, let 
your vendor know you need thefull source to discover what 
you need to reuse. If your Smalltalk vendor currently gives 
you all the source you need, call them and thank them, 
then tell them you expect the situation will not change if 
they don't want you running off to Hot Java! M 
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